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Abstract 


The Third Generation Partnership Project (3GPP) has identified cases 
where different SIP private header extensions referred to as "P-" 
header fields, and defined in RFC 7315, need to be included in SIP 
requests and responses currently not allowed according to RFC 7315. 
This document updates RFC 7315, in order to allow inclusion of the 
affected "P-" header fields in such requests and responses. 


This document also makes updates for RFC 7315 in order to fix 
misalignments that occurred when RFC 3455 was updated and obsoleted 
by RFC 7315. 

Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7976. 
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1. Introduction 


The Third Generation Partnership Project (3GPP) has identified cases 
where different Session Initiation Protocol (SIP) [RFC3261] private 
header extensions referred to as "P-" header fields, and defined in 
[RFC7315], need to be included in SIP requests and responses 
currently not allowed according to RFC 7315. This document updates 
RFC 7315, in order to allow inclusion of the affected "P-" header 
fields in such requests and responses. 


This document also makes updates for RFC 7315 in order to fix 


misalignments that occurred when RFC 3455 [RFC3455] was updated and 
obsoleted by RFC 7315. 
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As the "P-" header fields are mainly used in (and in most cases, only 
defined for) networks defined by the 3GPP, where the updates defined 
in this document are already defined [TS.3GPP.24.229], the updates 
are not seen to cause backward-compatibility concerns. 


2. Misalignments and 3GPP Use Cases 
2.1. General 


RFC 7315 contains contradicting statements regarding the usage of SIP 
"P—" header fields in SIP requests and responses, which leave the 
presence of the SIP "P-" header fields in the SIP requests and 
responses open to interpretation and different implementations. 
Statements in Section 5.7 of that RFC are not aligned with the 
definitions and usage of the SIP "P-" header fields specified in 
Section 4. This section describes the misalignments that occurred 
when RFC 3455 was updated and obsoleted by RFC 7315, and how they are 
fixed. 


NOTE: In the case of the P-Called-Party-ID header field, allowing it 
in PUBLISH requests was deliberately done in RFC 7315. Therefore, it 
is not considered a misalignment. 


Since RFC 7315 was published, 3GPP defined new use cases that require 
the RFC to be updated. This section describes the 3GPP use cases 
behind the updates, and the updates needed to RFC 7315 in order to 
support the use cases. 


Section 3 updates RFC 7315, based on the misalignments and 3GPP use 
cases. 


2.2. Misalignments 


The following updates are needed in order to fix the misalignments 
between RFCs 7315 and 3455: 


o P-Associated-URI: Remove the statement that the header field can 
appear in the SIP REGISTER method. 


o P-Called-Party-ID: Delete the statement that the P-Called-Party-ID 
header field can appear in SIP responses. Add a statement that 
the P-Called-Party-ID header field can appear in the SIP REFER 
method. 


o P-Visited-Network-ID: Delete the statement that the P-Visited- 
Network-ID header field can appear in SIP responses. Adda 
statement that the P-Visited-Network-ID header field cannot appear 
in the SIP NOTIFY, PRACK, INFO, and UPDATE methods. 
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o P-Access—-Network-Info: Add a statement that the P-Access-—Network-— 
Info header field can appear in SIP responses. 


o P-Charging-Vector: Add a statement that the P-Charging-Vector 
header field can appear in SIP responses. Add a statement that 
the P-Charging-Vector header field cannot appear in the SIP ACK 
method. 


o P-Charging-Function-Addresses: Add a statement that the 
P-Charging-Function-Addresses header field can appear in SIP 
responses. 


2.3. 3GPP Use Cases 
2.3.1. General 


The following updates are needed in order to implement the 3GPP use 
cases: 


o P-Access—-Network-Info: Add statement that the P-Access-—Network-— 
Info header field can appear in the SIP ACK method when triggered 
by a SIP 2xx response. 


o P-Charging-Vector: Add statement that the P-Charging-Vector header 
field can appear in the SIP ACK method when triggered by a SIP 2xx 


response. 
This following sections describe, for individual "P-" header fields, 
the 3GPP use cases that are the basis for the updates. The use cases 


are based on the procedures defined in [TS.3GPP.24.229]. 
2.3.2. P-Access-—Network-Info 


The P-Access-Network-Info header field may contain the Network 
Provided Location Information (NPLI). The NPLI is described in 
[TS.3GPP.23.228]. 


A proxy in possession of appropriate information about the access 
technology might insert a P-Access-Network-Info header field with its 
own values. Such values are identified by the string "network- 
provided" defined in RFC 7315. Based on operator policy and/or 
roaming agreement, the local time of the visited network may be 
included. 


The Call Data Records (CDRs) generated within the IP Multimedia 
Subsystem (IMS) have to contain the NPLI in order to guarantee 
correct billing. When an IMS session is modified, the NPLI also 
needs to be stored as the location of the user at the time when the 
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session is modified may generate a charging event. In case of a 
session modification event at IMS, the NPLI needs to be provided: 


o when the bearer establishment is triggered, or 
o at session release when the bearer deactivation is triggered, or 


o when the bearer modification is triggered, e.g., a QoS 
modification for the use of a newly negotiated codec. 


In some scenarios, the bearer modification may be triggered by the 
proxy upon reception of a Session Description Protocol (SDP) answer 
within SIP 2xx response to the SIP INVITE request. In such case, the 
NPLI needs to be provided within the SIP ACK request. However, RFC 
7315 does not allow the usage of the P-Access-—Network-Info header 
field in SIP ACK request. 


Upon reception of the SDP answer within SIP 2xx response on the SIP 
INVITE request, a proxy may initiate procedures to obtain the NPLI 
and may include the P-Access-—Network-Info header field with the NPLI 
in the SIP ACK request. 


The P-Access-Network-Info header field shall not be included in SIP 
ACK requests triggered by non-2xx responses. 


2.3.3. P-Charging-Vector 


RFC 7315 defines an Inter Operator Identifier (IOI) to enable 
different operators involved in a SIP dialog or a transaction outside 
a dialog to identify each other by exchanging operator identification 
information within the P-Charging-Vector header field. 


In the interconnection scenarios in multi-operator environments, 
where one or more transit operators are between the originating and 
terminating operator, the identities of the involved transit 
operators are represented by a transit-ioi parameter of the 
P-Charging-Vector header field. 


Transit operators can be selected independently for each SIP method 
and direction of request. A transit network will only have knowledge 
of an individual SIP request, and transit network selection will be 
an independent decision for each request and could be made based on 
load, cost, percentage, time of day, and other factors. For this 
reason, it is necessary that the P-Charging-Vector header field, 
which carries the transit IOI information, is included in each SIP 
request and response. However, RFC 7315 does not allow the usage of 
the P-Charging-Vector header field in the SIP ACK request. 
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A SIP proxy that supports this extension and receives the SIP ACK 
request may include a P-Charging-Vector header field in the SIP ACK 
request. 


The P-Charging-Vector header field shall not be included in SIP ACK 
requests triggered by SIP non-2xx responses. 


3. Updates to RFC 7315 
This section implements the update to Section 5.7 of RFC 7315, in 
order to implement the misalignment fixes and the 3GPP requirements 
described in Section 2. 


Old text: 


The P-Associated-URI header field can appear in SIP REGISTER method 


and 2xx resonses [Sic]. The P-Called-Party-ID header field can 
appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE 
methods and all responses. The P-Visited-Network-ID header field can 
appear in all SIP methods except ACK, BYE, and CANCEL and all 
responses. The P-Access-Network-Info header field can appear in all 


SIP methods except ACK and CANCEL. The P-Charging-Vector header 
field can appear in all SIP methods except CANCEL. The 
P-Charging-Function-Addresses header field can appear in all SIP 
methods except ACK and CANCEL. 


New text: 


The P-Associated-URI header field can appear in SIP REGISTER 2xx 
responses. The P-Called-Party-ID header field can appear in the SIP 
INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. The 
P-Visited-Network-ID header field can appear in all SIP methods 
except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE. The 
P-Access-Network-Info header field can appear in all SIP methods and 
non-100 responses, except in CANCEL methods, CANCEL responses, and 
ACK methods triggered by non-2xx responses. The P-Charging-Vector 
header field can appear in all SIP methods and non-100 responses, 
except in CANCEL methods, CANCEL responses, and ACK methods triggered 
by non-2xx responses. The P-Charging-Function-Addresses header field 
can appear in all SIP methods and non-100 responses, except in CANCEL 
methods, CANCEL responses, and ACK methods. 
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4. Security Considerations 


The security considerations for these "P-" header fields are defined 
in [RFC7315]. This specification allows some header fields to be 
present in messages where they were previously not allowed, and the 
security considerations and assumptions described in [RFC7315] (e.g., 
regarding only sending information to trusted entities) also apply to 
those messages. In addition, this specification also disallows some 
header fields to be present in messages where they were previously 
allowed. That does not cause any security issues, but implementors 
need to be aware that implementations may not have been updated 
according to this document, and take proper actions if a header field 
occurs, or does not occur, in a message where it should occur (or 
occurs in a message where it should not occur). This document adds 
the ability to include P-Access-Network-Info in ACK requests. As 
documented in [RFC7315], P-Access-Network-Info may include privacy 
sensitive information, including the user’s location. The security 
and privacy considerations for P-Access-—Network-Info in ACK requests 
are similar to those for the other SIP requests discussed in 


[RFC7315]. 
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